1. Field of the Invention
The field of the present invention relates to electronic hardware, including virtual, component design. In particular, the field of the present invention relates to the interfaces between components.
2. Background
The methodologies for designing, testing and manufacturing integrated circuits (ICs) continue to evolve. Today, with the continually increasing complexity and density of ICs, designing for reusability is becoming an overriding priority. One consequence of this priority is the increasing distinction of between the developers of potentially reusable functional component blocks, that when used with each other provide the foundation for an IC or the design of an IC, and the integrators of such blocks. A number of companies focus on the development of such functional block components. Some of the same companies as well as many others perform the integration and/or manufacturing of the ultimate ICs.
One of the new developments in circuit designs is the advent of so-called virtual component blocks, which, from a general standpoint, are pre-designed and pre-hardened (or semi-hardened) circuit designs in software form (for example, in GDSII format), which can be readily re-used or recycled in different, larger circuit designs. An advantage of virtual component (or VC) blocks is that they reduce the time to design an overall circuit, and thereby, increase the speed to market.
The breakdown of IC development into the design of discrete functional components, and the fact that there are many providers of such components, has in part been responsible for the creation of a need to have a standard interface for communicating between components. This is one of the goals of the Virtual Socket Interface Alliance (VSIA) Virtual Component Interface (VCI) Standard. A draft of this standard, Standard 2 Version 1.0 (Working Revision (Feb. 2, 2000) is attached as an appendix. To meet this stated goal, which includes objectives of connectability, flexibility, and portability of component blocks, the VCI protocol, as outlined in the specification, has been developed with an eye towards simplicity.
A preference for simplicity in the VCI protocol, in turn, has necessarily led to certain requirements to which component blocks that adopt the protocol must adhere. A first requirement is that one side of the interface is required to act as a master or initiator of a communication and the other side is required to act as a slave or target for the communication. As such, the design of the target interface has inherent differences from that of the initiator interface. Specifically, each side of the interface, by definition, comprises different logic to enable each side to perform its predefined role in the communication. Because of these complementary functions, the inputs and outputs on each side of the interface are also different from each other. The pins on each side of the interface to which connections are made represent a type of signal input or output that is generally specific to that side of the interface.
Another requirement is that the VC Interface of a functional block be a unidirectional interface. Output pins on one side of the interface are connected to input pins on the other side of the interface, such that signals travel in only one direction for a given connection.
Thus, functional components (including virtual components (VCs)) that include a VC interface can act only as targets or initiators in a point-to-point communication. As such, in any communication between two components, if one component is defined as a master, the other must be a slave, and vice versa.
In any methodology for designing ICs based on predefined component blocks, one of the first steps is to specify, as a starting point, the component blocks that will be used as the foundation of the design. One such component block that is identified at this stage is the foundation block, a block that typically comprises a processor, some memory and a communication block. The communication block has the primary purpose of transferring data from one place to another, and in the context of IC design includes a bus connected to multiple I/O ports. The foundation block often manages the communication between most if not all of the other component blocks to be used in the IC. Because it includes a communication block, the foundation block typically includes on its edges a large number of ports, of which some are initiators and others are targets. Because of the requirements of standard protocols such as the VCI protocol, the type of interface at a particular location on the edge of a foundation block must be predefined. Thus, characterizing the foundation block that is to be used for a given IC typically requires specifying a bus and the number, locations and types of ports on the edges of the block. For example, one common layout of ports for a foundation block is to position them evenly around the foundation block to provide for floor-planning flexibility.
One of the next steps is specifying the placement of the component blocks, including the foundation block, to form the layout of the IC. In this process, chip designers try to minimize wire lengths between pins of different components and minimize the overall area or footprint of the IC. Increasingly, these connection distances are the greatest speed-limiting factor in efforts to increase the speed and performance of an IC.
To assist in optimizing the layout of the IC, chip designers often use electronic design automation (EDA) software tools. The component blocks are automatically “placed” (i.e., given specific coordinate locations in the circuit layout) and “routed” (i.e., wired or connected together according to the designer's circuit definitions). The placement and routing software routines generally accept as their input a flattened netlist that has been generated by a prior logic synthesis process. This flattened netlist identifies the specific components from a component library, and describes the specific component-to-component connectivity. After this specific connectivity has been established, the physical design and layout software creates a physical layout file of the integrated circuit, including the physical position of each metal line (i.e., wire) and each via (i.e., metal transition between chip layers).
Further explanation of a particular chip design process is set forth, for example, in U.S. Pat. No. 5,838,583, hereby incorporated by reference as if set forth fully herein.
Because the ports for the foundation block are specified before the layout process can be performed, the flexibility in component block placement is potentially limited by the locations and types of ports that have been specified. Essentially, the capability of optimizing a design footprint or achieving minimum connection lengths, and thereby, the IC's overall speed and performance, is compromised.
A need exists therefore, for a way of optimizing for speed and performance in an electronic design without incurring the limitations inherent in a predefined foundation block or other functional block.